Skip to content

Conversation

@ePaul
Copy link
Member

@ePaul ePaul commented Oct 7, 2025

Triggered by a discussion in an internal chat (internal link), this makes it clearer which of the compatibility rules apply for input and output schemas, respectively.

@ePaul ePaul added the editorial label Oct 7, 2025
@ePaul ePaul force-pushed the compatibility-separately-for-input-output branch from 7154a27 to 099c0c6 Compare October 8, 2025 08:47
@ePaul ePaul added the major Major feature changes or updates, e.g. feature rollout to a new country, new API calls. label Oct 8, 2025
Copy link
Member

@tfrauenstein tfrauenstein left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for providing more clarity on compatible changes -- it is needed.
I provided some change proposals to further enhance clarity and avoid redundancies.

Comment on lines 89 to 99
* Add only optional, never mandatory fields.
* Don't remove any fields.
* Don't make mandatory fields optional or make optional fields mandatory.
* Input fields may have (complex) constraints being validated via server-side
business logic. Never change the validation logic to be more restrictive and
make sure that all constraints are clearly defined in description.
* `enum` ranges can be reduced only if the server is ready to still accept and
handle old values. They **cannot** be extended.
* You <<112>> that are used for output parameters and likely to
be extended with growing functionality. The API definition should be updated
first before returning new values.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Add only optional, never mandatory fields.
* Don't remove any fields.
* Don't make mandatory fields optional or make optional fields mandatory.
* Input fields may have (complex) constraints being validated via server-side
business logic. Never change the validation logic to be more restrictive and
make sure that all constraints are clearly defined in description.
* `enum` ranges can be reduced only if the server is ready to still accept and
handle old values. They **cannot** be extended.
* You <<112>> that are used for output parameters and likely to
be extended with growing functionality. The API definition should be updated
first before returning new values.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is is a consequence of the sentence before, and redundant -- should be omitted.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having the redundant information makes it easier to follow, was my idea. Though I also understand the desire to keep the rules shorter.

ePaul and others added 6 commits November 11, 2025 21:46
editorial changes: remove redundant text.

Co-authored-by: Thomas Frauenstein <[email protected]>
editorial improvements about optional/mandatory fields

Co-authored-by: Thomas Frauenstein <[email protected]>
editorial changes about mandatory/optional for output.

Co-authored-by: Thomas Frauenstein <[email protected]>
remove redundand "when used for output".

Co-authored-by: Thomas Frauenstein <[email protected]>
Co-authored-by: Thomas Frauenstein <[email protected]>
@ePaul
Copy link
Member Author

ePaul commented Nov 27, 2025

👍

1 similar comment
@tfrauenstein
Copy link
Member

👍

@tfrauenstein
Copy link
Member

👍

1 similar comment
@ePaul
Copy link
Member Author

ePaul commented Nov 27, 2025

👍

@ePaul ePaul merged commit 6750588 into main Nov 27, 2025
4 checks passed
@ePaul ePaul deleted the compatibility-separately-for-input-output branch November 27, 2025 16:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

editorial major Major feature changes or updates, e.g. feature rollout to a new country, new API calls.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants